Environment for Agile Teams by Andy Brandt

Author:Andy Brandt [Andy Brandt]
Language: eng
Format: epub, mobi, pdf
Publisher: leanpub.com
Published: 2013-03-20T04:00:00+00:00

Metrics, bonuses etc.

Don’t count hours

One of the most nonsensical activities many managers engage in is counting hours – registering hours worked and judging people based on how many hours they spent bent over their keyboards at the office.

The worst approach here is of course paying by the hour. It not only gives people an incentive to work slow - it practically forces them to cheat.

The official work day is 8 hours, but it is virtually impossible to be really working all that time. Plus when you work as a software developer it may be really challenging to count time appropriately - does thinking about an algorithm in the restroom count? How about searching the net randomly looking for inspiration? Is e-mail work or not? How to measure time spent on context switching after being interrupted with a phone call, a colleague asking a question and so on?

If you have ever filled in time sheets in your life you know yourself how much they are worth. The information contained there is at best inaccurate. Of course, people don’t cheat to the point of reporting they have been in the office when they were absent. They just make sure hours reported add up to what is required and expected. And indeed this is accepted by most employers. But it makes it ok to color the reality a bit, stretch the truth and this is introducing an element of dishonesty that I object to here.

But apart from that the number of hours worked is a completely useless metric for creative work of any kind - and especially creative team work. Since hour is incomparable to hour and work is non-linear, not easily measurable (how to measure how good a piece of code is?) this number doesn’t give any usable information about your organization.

It is actually a legacy of the industrial age and “punch clocks” used to measure time spent by workers on factory floor. Back then it made sense, since the worker was actually an extension of a machine installed in the factory supplying intelligence the machine lacked. The problems he was solving were simple and limited to what was needed to perform well the task the machine was built for. Therefore the worker’s productivity was zero once he walked away from his machine.

This logic is not applicable to software development. Contrary to what people unfamiliar with it may think it is not the computer that is the primary development tool. It is the developers’ brain. Most of the work is done there, typing on the keyboard is merely a consequence, a result of the thinking going on inside. Therefore, a developer can be sitting in front of his computer completely unproductive - and he can be also thinking hard about a problem when driving home, in the gym or in the shower. Measuring hours spent in the office serves no real purpose then, because we can’t externally distinguish “productive” from “unproductive” hours.

Be careful with metrics

Something I see in many managers I work

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.